home *** CD-ROM | disk | FTP | other *** search
Text File | 2002-10-03 | 55.2 KB | 1,057 lines
GGGGRRRR____OOOOSSSSVVVVIIIIEEEEWWWW((((1111)))) GGGGRRRR____OOOOSSSSVVVVIIIIEEEEWWWW((((1111)))) NNNNAAAAMMMMEEEE gr_osview - graphical system monitor SSSSYYYYNNNNOOOOPPPPSSSSIIIISSSS gr_osview [----hhhhVVVVLLLLeeeeaaaappppzzzzEEEEFFFF] [----DDDDfile] [----ssssfile] [----NNNN[user@]node] [----nnnnnamelist] DDDDEEEESSSSCCCCRRRRIIIIPPPPTTTTIIIIOOOONNNN This command provides a graphical display of usage of certain types of system resources. This display provides a real-time window into the overall operation of the system. The main display element is a rectangular area which is filled by uniquely colored bands, each band signifying a sampled variable measuring system performance. This rectangular area is called a _b_a_r throughout the rest of this description. Each bar in a window has a header which consists of the bar title plus the names of each variable displayed, in colors to match those used for each band in the bar. The colors used, as well as size, layout, background and foreground colors may be modified. _g_r__o_s_v_i_e_w is implemented using a client-server model. The server side acts as a simple display engine, while the client acts as a data generator. By default, client and server are invoked as a tightly coupled process for optimal performance. However, the client (data- collection) side can be automatically run on a remote machine while the server runs locally, allowing remote monitoring of system performance. Server and client operation can be used independently through the use of _g_r__o_s_v_i_e_w "export" files, allowing recording and playback of performance monitoring sessions. This man page describes VVVVeeeerrrrssssiiiioooonnnn 2222....2222 of _g_r__o_s_v_i_e_w. Setup files from previous versions of gr_osview are accepted, however remote operation is only possible with a _g_r__o_s_v_i_e_w of the same version. _g_r__o_s_v_i_e_w is driven by a setup file. The setup file may be explicitly named on the command line, found through an environment variable, or in the caller's home directory. A complete description of the format and additional capabilities of the setup file is given below. OOOOPPPPTTTTIIIIOOOONNNNSSSS The following options are supported: -h Print a summary of the available options. -D file This option specifies where the setup file will come from. If the file "-" is named, then the setup will be read from standard input. If this option is not specified, the environment variable GROSVIEW is checked for a setup file name. If this variable is not set, then a file named ".grosview" is scanned for in the invoker's home directory. If all this fails, a default setup of a single CPU usage bar is used. PPPPaaaaggggeeee 1111 GGGGRRRR____OOOOSSSSVVVVIIIIEEEEWWWW((((1111)))) GGGGRRRR____OOOOSSSSVVVVIIIIEEEEWWWW((((1111)))) _g_r__o_s_v_i_e_w will automatically recognize a _g_r__o_s_v_i_e_w "export" file if found instead of a setup file. This causes _g_r__o_s_v_i_e_w to automatically act as a display server, playing back the data in the file. -s file This option specifies the creation of an "export" file. This file is an ASCII text file containing the information needed to initialize the display server properly, followed by an arbitrary number of data samples. -N [user@]host Contact the remote host, using the given user ID if specified, and monitor that host's performance on the local machine. The window border is forced in this case, and the argument is used as the window title. If user is not specified, the user ID "guest" is used. _g_r__o_s_v_i_e_w will automatically attempt to re-connect to the remote system if the connection is lost for some reason. If system errors or other problems which would preclude successful reconnection are present, then _g_r__o_s_v_i_e_w will simply exit. -F This option suppresses text output. This can be useful in several situations, for instance when creating a very small _g_r__o_s_v_i_e_w display where the text would be illegible anyway. As a side effect, max value and average counters, and the scale for absolute bars are suppressed. -E This option directs _g_r__o_s_v_i_e_w to act simply as a data generator, and an "export" file will be written to standard output, with continuous writing of sampled data until the program is killed. The ----DDDD option is handled as expected, except that if an "export" file is passed, _g_r__o_s_v_i_e_w uses only the initialization information and generates new data samples from the running system. -V Print the current version and copyright information for the program. -a This option invokes a subset of the displayable bars that includes: cpu usage, memory usage, cpu wait time, system activity and graphics activity. -p This option prints the window position and size after the window has been laid out on standard input. This is useful for programming setup scripts. -z This option enables "freeze" toggling. Sending SIGUSR1 (see _s_i_g_n_a_l(_2)) to _g_r__o_s_v_i_e_w will freeze and unfreeze the display. If currently generating a _g_r__o_s_v_i_e_w "export" file, it will also stop any output to the file. This is useful when doing screen dumps or snapshoting particular events. PPPPaaaaggggeeee 2222 GGGGRRRR____OOOOSSSSVVVVIIIIEEEEWWWW((((1111)))) GGGGRRRR____OOOOSSSSVVVVIIIIEEEEWWWW((((1111)))) -e This option is only effective when _g_r__o_s_v_i_e_w is reading an "export" file. It instructs _g_r__o_s_v_i_e_w to exit when the data in the file is exhausted. By default, the display window is left up, frozen at the last data sample. -L This option causes _g_r__o_s_v_i_e_w to lock down those pages which it actually uses while running and prevent the process from swapping. This enables a minimum number of pages to be locked while keeping _g_r__o_s_v_i_e_w performing as a real-time display under heavy system load. -n This option causes _g_r__o_s_v_i_e_w to use a kernel namelist other than the default, ////uuuunnnniiiixxxx.... This option is currently not supported with -N. OOOOVVVVEEEERRRRVVVVIIIIEEEEWWWW There are three potential formats for each bar, with various optional features. Each bar has a header line, which gives the bar name and the names of its parameters, plus some additional information depending on the bar type. Below this is the actual bar. Parameters are such things as the various elements of CPU usage: user time, system time, interrupt overhead and idle time. The text of a parameter name in the header is colored to match the associated part of the bar display. The most common format is called _m_o_v_i_n_g _b_a_r _f_o_r_m_a_t. In this format, the information is displayed as a sectioned bar, each section being a different color. As time passes, each section will be redrawn with its length adjusted proportionally to the value of the parameter. To obtain smooth motion, and damp peaks and valleys which would otherwise be visually confusing, each section of the bar is averaged over a specific number of intervals. For instance, if a parameter doubles in value, the section will gradually double in length over a certain number of samples. By setting the sample interval, the user can control the update rate of the bar information. The default is 2/10 second, which provides smooth visual motion. A bar border is supplied by default which includes a heavy lower border marked in 1/10 increments for easier estimation. This border can be suppressed completely, or the ruler can be suppressed. There are two subformats for the moving bar: relative and absolute. In relative mode, the displayed values must all add up to 100% and are relative only to each other. In absolute mode, the bar displays an indicator of events per second over the sample interval, and the header includes the sample interval. The bar itself will auto-scale; this means that the scale used will vary automatically (with some hysteresis) as the number of events changes. The scale value being used is displayed above the right-hand edge of the bar. The property of relative or absolute display is a characteristic of the type of data being displayed, and is not under control of the user. The scale value can be _l_o_c_k_e_d, in which case autoscaling is disabled, and the scale value is inverted in color to indicate locked operation. The user may specify that the bar scale be locked and its value. If instead PPPPaaaaggggeeee 3333 GGGGRRRR____OOOOSSSSVVVVIIIIEEEEWWWW((((1111)))) GGGGRRRR____OOOOSSSSVVVVIIIIEEEEWWWW((((1111)))) the user asks the scale to _c_r_e_e_p, the scale factor will only increase, and never decrease. The second format is called _s_t_r_i_p _c_h_a_r_t _f_o_r_m_a_t. Any moving bar may also be displayed as a strip chart. In this mode, instead of being displayed horizontally, the bar is drawn vertically at the right hand edge of the bar after moving the bar down by the size of a single sample. This forms a strip-chart effect. The number of samples and the sample interval can be changed. The header of an absolute bar displayed as a strip chart will indicate the overall time shown by the strip instead of the sample interval time. Finally, tick marks may be added to the strip to ease estimation. If the strip chart format is used for an absolute bar type, and the scale is not locked, then autoscaling causes an additional action. When the scale changes, a red line is drawn through the bar at the point at which the scale changed, and the remainder of the bar is drawn in a gray color, showing only the outline of the parameter values. This shows that the scale changed, and the grayed out data is invalid. In either of the above bar formats, and if the bar type is absolute, then some additional display options are available. In _m_a_x _v_a_l_u_e _m_o_d_e, the bar display area is compressed and a text field is added to the right of the bar showing the maximum value ever achieved by the sum of the parameters. By default, this number is displayed as red on black, in the upper part of the bar area. If the user desires, then this maximum can be automatically reset to a lower value if the current value remains below it for some number of intervals. This gives the effect of a "peak" meter, holding a maximum long enough for the user to note it. If _t_r_a_c_k_i_n_g _m_o_d_e is enabled, then a text field is added at the right of the bar below the maximum value field showing the average of the sum of the parameters over an interval. By default, this number is displayed as blue on white. Each of these modes displays a calculated events-per-second ratio. If the sample interval is much smaller than one second, then the displays will show the "burst" rate achieved at the sample interval. The system may not be able to sustain this rate over longer periods of time. To get an accurate measure at any interval, simply adjust the sample interval as described below. The number shown for each of these modes, as well as the value used for scaling, are usually calculated for a subset of the parameters shown in the bar. For example, if displaying memory usage, the counters and scale will not include the free memory in the system. The third main format is _n_u_m_e_r_i_c _f_o_r_m_a_t. This format is currently only available for absolute value bar types. Instead of a graphic display, the bar is replaced by a text display area in which the actual values of the parameters are displayed. In contrast to the other displays, the parameter values are given over the whole sample interval rather than PPPPaaaaggggeeee 4444 GGGGRRRR____OOOOSSSSVVVVIIIIEEEEWWWW((((1111)))) GGGGRRRR____OOOOSSSSVVVVIIIIEEEEWWWW((((1111)))) scaled to units per second. This allows a long sample time for slow changing parameters. By default, the current values of the parameters are displayed in the same color as the graphical display would use just below each parameter name in the header. If _m_a_x _v_a_l_u_e _m_o_d_e is turned on, then a listing of the maximum value seen for each parameter is given below the current values, except that all text is displayed in the current maximum display foreground color, which is red by default. If _t_r_a_c_k_i_n_g _m_o_d_e is turned on, then the average numeric values are summed and displayed to the right in the foreground color, with an appropriate title. The behavior of the _m_a_x _v_a_l_u_e and _a_v_e_r_a_g_e modes is intuitively similar to that for a moving bar, except each parameter is handled independently. SSSSEEEETTTTUUUUPPPP FFFFIIIILLLLEEEE The setup file provides a simple mechanism for initializing a large number of possible parameters for the _g_r__o_s_v_i_e_w display. The setup file is an ASCII file. Comment lines are delimited by a # character in the first column, and blank lines are ignored. In addition, trailing comments may be added using a # character, after which all data on the line is ignored. Lines containing information may be classed into two types, _m_o_n_i_t_o_r lines and _o_p_t_i_o_n lines. _M_o_n_i_t_o_r lines describe the format of an individual bar, while _o_p_t_i_o_n lines describe global parameters. The monitor bars in the _g_r__o_s_v_i_e_w window are brought up in the same order they are found in the setup file. A particular monitor bar may be entered several times, possibly with many different options. Each monitor line consists of a name followed by zero or more modifier options. The following monitor bars are available: cpu - monitor CPU usage rmem - monitor real memory usage rmemc - monitor real memory usage wait - monitor time waiting for I/O sysact - monitor important system activity gfx - monitor important graphics activity bdev - monitor block device throughput fault - monitor page faults tlb - monitor TLB activity intr - monitor interrupts pswap - monitor page swapping activity nettcp - monitor TCP protocol activity netudp - monitor UDP protocol activity netip - monitor IP layer activity netif - monitor network interface activity disk - monitor disk usage swp - monitor logical swap space The ccccppppuuuu, nnnneeeettttiiiiffff and ddddiiiisssskkkk bars have special formats. The ccccppppuuuu bar may have an optional argument which indicates a particular CPU to monitor (if more than one is present in the system). In this case, the descriptor takes PPPPaaaaggggeeee 5555 GGGGRRRR____OOOOSSSSVVVVIIIIEEEEWWWW((((1111)))) GGGGRRRR____OOOOSSSSVVVVIIIIEEEEWWWW((((1111)))) the form: cpu(n) - monitor CPU number _n If the word _s_u_m is given instead, the bar monitors the sum of all CPU activity in the system in a single bar. The nnnneeeettttiiiiffff bar may have an optional argument which indicates a particular interface to monitor, or it may indicate that only the sum of all network interface activity is to be monitored. By default, a bar is generated for each network interface on the system except for the local loopback interface. If a name is given, the descriptor takes the form: netif(name) - monitor interface name _n_a_m_e Typical interface names are _e_t_0, for the built-in ethernet interface on the POWERSeries, _l_o_0 for the local loopback interface, _e_n_p_0 for the standard Professional IRIS VMEbus ethernet card, and _e_c_0 for the Personal IRIS built-in ethernet interface. If the word _s_u_m is given instead, the bar monitors the sum of all interface traffic for the system. The ddddiiiisssskkkk bar requires an argument describing the volume to monitor. The form of the descriptor is: disk(path) - monitor the volume given by _p_a_t_h The _p_a_t_h argument can name a filesystem in one of two ways. If it names a block special device, then that device is assumed to contain an EFS, XFS or UDF filesystem, and usage is monitored with the special file name used as the bar header. Otherwise, the argument is assumed to name a file residing on some mounted volume. The path name passed in is used as the header. The bar scale is set at the number of megabytes of storage on the volume. The scale number for the real memory bars, rrrrmmmmeeeemmmm and rrrrmmmmeeeemmmmcccc, is the number of memory pages in the system. On current SGI systems, each page can be 4096 or 16384 bytes in length depending on the return value of the _g_e_t_p_a_g_e_s_i_z_e(2) system call. In general, the larger page size is used on systems where _u_n_a_m_e(_1) returns "IRIX64". For the ssssyyyyssssaaaacccctttt, ggggffffxxxx, iiiinnnnttttrrrr, bbbbddddeeeevvvv, ffffaaaauuuulllltttt, ppppsssswwwwaaaapppp, nnnneeeettttuuuuddddpppp, nnnneeeettttiiiipppp, nnnneeeettttiiiiffff, ttttllllbbbb bars, the scale will show the calculated number of events per second which would fill the bar. For the ddddiiiisssskkkk bar, the scale value will show the total size of the disk in bytes. For the sssswwwwpppp bar, the scale value will show the total amount of logical swap. The ccccppppuuuu and wwwwaaaaiiiitttt bars cannot be displayed as numeric bars. If the bbbbddddeeeevvvv, nnnneeeettttuuuuddddpppp, nnnneeeettttiiiipppp or nnnneeeettttiiiiffff bars are displayed as numeric bars then additional information is available. The following options may be supported for each of the above bar types. If the option is unsupported, it will be silently ignored by _g_r__o_s_v_i_e_w. strip - display as a strip chart numeric - display numeric values PPPPaaaaggggeeee 6666 GGGGRRRR____OOOOSSSSVVVVIIIIEEEEWWWW((((1111)))) GGGGRRRR____OOOOSSSSVVVVIIIIEEEEWWWW((((1111)))) max - add a maximum value numeric meter max(n) - add a maximum value meter with reset interval n tracksum - add an average value numeric meter tracksum(n) - add an average value meter with interval n noborder - suppress bar border interval(n) - set sample interval in base units samples(n) - set number of samples in strip chart attack(f) - set attack speed of bar colors(c,...) - set bar colors to use maxcolor(b,f) - set maximum value display colors limcolor(b,f) - set scale limit value display colors sumcolor(b,f) - set tracking sum display colors lockscale(x) - lock the scale value creepscale - autoscaling will only increase the scale ticks(i,n) - set strip chart tick marks A strip chart is a pictorial representation of a number of samples from the given bar, displayed vertically rather than horizontally. The header displays the total time covered by the bar, which is the interval times the number of samples. A numeric chart simply shows the monitored values as absolute numeric values rather then as pictorial values. The mmmmaaaaxxxx enables max value mode, while the ttttrrrraaaacccckkkkssssuuuummmm option enables average value tracking mode. If the second form of mmmmaaaaxxxx, is used, the argument indicates a number of intervals after which the max value will be reset to the current value, if the current value remains below the displayed max value. In the second form of ttttrrrraaaacccckkkkssssuuuummmm, the argument specifies the number of intervals over which to average the value. This allows, for instance, a moving bar to react very quickly for good visual effect while the average value is computed over a longer interval for more accuracy. These values are displayed at the end of a bar, the mmmmaaaaxxxx value above the ttttrrrraaaacccckkkkssssuuuummmm value. If the nnnnoooobbbboooorrrrddddeeeerrrr option is given, then the bar border is suppressed. The iiiinnnntttteeeerrrrvvvvaaaallll option specifies the update interval of the bar, in base interval units. The base interval is set as a global option; see below. The argument to this option indicates the number of base interval units in the interval for this bar. For instance, if the base interval is .2 seconds, then an argument of "5" would indicate a 1 second interval. The aaaattttttttaaaacccckkkk option specifies the percentage of the new value to be used in the rolling average calculation. This averaging is what makes each bar appear to move smoothly; changing the attack value can change the speed and appearance of a bar substantially. The value can range from 0.0 to 1.0; of course 0.0 indicates no movement of the bar ever, while 1.0 means instant change to the next value. The ccccoooolllloooorrrrssss option modifies the colors used for the bar. Starting from the first parameter in a bar, the colors are modified until either all parameters are modified or no more colors are specified. Each color specified in the argument is a color map index to use for that color. PPPPaaaaggggeeee 7777 GGGGRRRR____OOOOSSSSVVVVIIIIEEEEWWWW((((1111)))) GGGGRRRR____OOOOSSSSVVVVIIIIEEEEWWWW((((1111)))) The mmmmaaaaxxxxccccoooolllloooorrrr, lllliiiimmmmccccoooolllloooorrrr and ssssuuuummmmccccoooolllloooorrrr options set the background and foreground colors, respectively, of that type of display for this bar. The lllloooocccckkkkssssccccaaaalllleeee option locks the scale value for the bar to the given value, disabling autoscaling. A locked scale is indicated by the scale value being inverted (reverse video) in the display. If the numeric argument to lllloooocccckkkkssssccccaaaalllleeee is suffixed by a 'k' or 'K', then the argument is multiplied by 1024, a 'm' or 'M' suffix multiplies the argument by 1 meg (1024 times 1024), or a 'g' or 'G' suffix multiplies the argument by 1 gig (1024 times 1024 times 1024). The ccccrrrreeeeeeeeppppssssccccaaaalllleeee option allows autoscaling, but the scale can only increase. The ttttiiiicccckkkkssss option enables tick marks for the given strip. Tick marks are painted at the top of the bar, and follow the strip as it moves. The first form, _t_i_c_k_s(_n), paints a tick mark every _n samples. The second form, _t_i_c_k_s(_n,_m), paints a double-length tick mark every (_n*_m) samples, or every _m normal tick marks. Global options are introduced by a line with the special descriptor oooopppptttt beginning the line. The following global options are accepted: noborder - suppress borders on all bars arbsize - allow arbitrary window sizing width(w) - set number of bars horizontally interval(t) - set base sample interval colors(c,...) - modify default color behavior maxcolor(b,f) - set colors for maximum value displays limcolor(b,f) - set colors for limit value displays sumcolor(b,f) - set colors for sum value displays backcolor(c) - set background color frontcolor(c) - set foreground color font(f) - set font to use origin(x,y) - set window origin winsize(x,y) - set window size nodecorate - request an unframed window The nnnnoooobbbboooorrrrddddeeeerrrr option suppresses borders on all bars, making each bar display seem to "hang in space". The aaaarrrrbbbbssssiiiizzzzeeee option allows arbitrary sizing of the window; _g_r__o_s_v_i_e_w may not always be able to properly scale text or draw to match the window size if it is too small. The acceptability of a too-small display is left to the user. The wwwwiiiiddddtttthhhh option sets the number of bars horizontally to use. This value is one by default, meaning that a long, vertical display is used. The iiiinnnntttteeeerrrrvvvvaaaallll option sets the base sample interval. The argument is given in tenths of seconds. The default base interval is two tenths of a second. The ccccoooolllloooorrrrssss option sets the global color table, from which each bar selects its default colors, in the same manner as for an individual bar. The lllliiiimmmmccccoooolllloooorrrr, mmmmaaaaxxxxccccoooolllloooorrrr and ssssuuuummmmccccoooolllloooorrrr options set the background and foreground colors, respectively, of the limit value, maximum value and tracking sum value displays. The bbbbaaaacccckkkkccccoooolllloooorrrr and ffffrrrroooonnnnttttccccoooolllloooorrrr options set the general background or foreground colors respectively. PPPPaaaaggggeeee 8888 GGGGRRRR____OOOOSSSSVVVVIIIIEEEEWWWW((((1111)))) GGGGRRRR____OOOOSSSSVVVVIIIIEEEEWWWW((((1111)))) The ffffoooonnnntttt option sets the font to be used for text. This is a font name as known to the IRIS GL Font Manager (libfm). Default is "TimesBoldItalic". The oooorrrriiiiggggiiiinnnn option specifies the initial origin of the window in screen coordinates. The wwwwiiiinnnnssssiiiizzzzeeee option sets the initial window size in screen coordinates. Setting the nnnnooooddddeeeeccccoooorrrraaaatttteeee option specifies a _g_r__o_s_v_i_e_w window with no borders. The default is to request a border around the window. IIIINNNNTTTTEEEERRRRPPPPRRRREEEETTTTIIIINNNNGGGG TTTTHHHHEEEE DDDDIIIISSSSPPPPLLLLAAAAYYYY ccccppppuuuu The cpu bar statistically monitors the distribution of CPU cycles between user programs, the operating system, interrupt overhead, graphics and idle time. Computation-intensive loads will show large user times, while I/O or kernel service intensive loads will show up as increased system and interrupt time. If intensive graphics activity is under way, then the time spent waiting for the graphics hardware to context switch and the time spent waiting for the graphics FIFO to empty will consume a significant portion of the processor. _g_r__o_s_v_i_e_w perturbs this slightly, since it causes graphics context switches to occur. The data is collected by sampling the program counter at the kernel clock frequency, which is 100HZ on the 4D series. This sampling is done automatically by the operating system; _g_r__o_s_v_i_e_w simply collects the data and displays it. wwwwaaaaiiiitttt The wait bar monitors the percentage of time that the system is idle due to waiting for outstanding I/O requests. If an I/O request was issued on a processor, then time that that processor spends idle will be viewed as wait time. This bar is constructed by summing all the idle time for all processors in the system and displaying the percentage of that time that an I/O request was pending. Since in a multiprocessor system, there is no way to differentiate which processors have I/O pending, if there is any outstanding I/O request, and a processor goes idle, that processor (along with all other idle processors) will accumulate wait for I/O time rather than idle time. The different forms of waiting are: IIIIOOOO refers to time spent waiting for traffic related to file system accesses (including local, remote, and mapped files, and normal file read and write). SSSSwwwwaaaapppp refers to time spent waiting for paging and swapping operations to and from any swap devices. PPPPiiiioooo refers to time spent waiting for physical IO to complete; for example, direct DMA to user space. The information is collected in the same way as cpu time. The meaning of the wait bar changed in the IRIX 6.5.13 release. For details, see the ----UUUU section of ssssaaaarrrr(1) man page. PPPPaaaaggggeeee 9999 GGGGRRRR____OOOOSSSSVVVVIIIIEEEEWWWW((((1111)))) GGGGRRRR____OOOOSSSSVVVVIIIIEEEEWWWW((((1111)))) rrrrmmmmeeeemmmm This bar measures real memory usage. kkkkeeeerrrrnnnneeeellll memory is memory allocated to the operating system and drivers. ffffssss ccccttttllll is memory used to store filesystem meta-data, that is, information such as inodes, bitmaps, directories and the like that are used to manage file data. ffffssssddddiiiirrrrttttyyyy memory is occupied by modified file system pages which have not yet been written to backing store. ffffsssscccclllleeeeaaaannnn memory is occupied by unmodified file system pages which are currently attached to file system buffer headers. ffffrrrreeeeeeee is memory not currently in use. uuuusssseeeerrrr is memory currently allocated to running processes. Note that some of the pages marked ffffsssscccclllleeeeaaaannnn or ffffssssddddiiiirrrrttttyyyy may also be allocated to running processes, but will not be accounted as uuuusssseeeerrrr memory. Note also that some of the ffffrrrreeeeeeee memory may represent file system data. Memory data is collected as absolute numbers rather than with statistical means, such as for cpu usage. Most bars listed here use this kind of accurate data, unless stated otherwise. rrrrmmmmeeeemmmmcccc This bar is the same as the rrrrmmmmeeeemmmm bar, except that two fields are used to describe memory not currently in use: ffffrrrreeeeeeeecccc is unused memory which contains valid backing-store data and which may be reclaimed by a process or by the file system buffer cache; ffffrrrreeeeeeeeuuuu is unused memory which contains no usable data. ssssyyyyssssaaaacccctttt The system activity bar measures a few of the important system activities, namely total system calls, process context switches, fork, exec and iget operations. FFFFoooorrrrkkkk operations are initiated by a process when it wishes to create a new process. EEEExxxxeeeecccc operations are initiated by a process to overlay itself with a new process; this is how a new program image is loaded and run. Finally, an iiiiggggeeeetttt operation occurs whenever the state of a file is changed, for instance when it is opened. This is a crude measure of file system activity. It is important to note that _g_r__o_s_v_i_e_w adds to the totals shown in this bar, since it to must perform at least some system calls, and causes some process context switches. ggggffffxxxx This bar monitors graphics activity on the system. On most systems, the graphics hardware can interrupt the CPU when certain conditions occur; the first bar element measures the amount of such activity, named iiiinnnnttttrrrr. Every time the processor switches to a new process which is using a GL window on the graphics screen, a graphics context switch occurs, labeled sssswwwwcccchhhh. The X server and GL graphics programs will sometimes interact with privileged code in the kernel to obtain some service; this is labeled iiiiooooccccttttllll after the system call used to perform the service. When a GL graphics program wishes to be synchronized with buffer swapping done during double buffering, it must wait for the next vertical retrace. The number of times this happens is labeled sssswwwwaaaapppp. PPPPaaaaggggeeee 11110000 GGGGRRRR____OOOOSSSSVVVVIIIIEEEEWWWW((((1111)))) GGGGRRRR____OOOOSSSSVVVVIIIIEEEEWWWW((((1111)))) Finally, the graphics pipeline is preceded by a FIFO buffer to smooth data movement into the pipeline. When the FIFO fills up, which it can with a fast processor, it interrupts the host, which waits until the FIFO has emptied somewhat before allowing the graphics process to continue drawing. The ffffiiiiwwwwtttt element describes the number of times this has happened. The ffffiiiinnnnoooowwwwtttt element describes the number of times the interrupt routine found that the FIFO was below the low-water mark by the time it had saved state and entered the interrupt handler. bbbbddddeeeevvvv This bar (titled "BufAct") monitors the input/output activity to block devices. Block devices are usually those which hold filesystems, thus this bar measures filesystem throughput. The values are given in blocks per second, each block being 512 bytes in length. If displayed as a numeric bar, then the logical read and write rates as well as the actual read and write rates, are displayed, as well as the hit ratio of logical to actual reads and writes and the rate at which delayed writes are cancelled (due, for example, to truncation requests). ffffaaaauuuulllltttt This bar monitors page fault activity. These are events that occur in managing the virtual address space of a process. The types of events are: ccccppppwwww These are _c_o_p_y-_o_n-_w_r_i_t_e events. This occurs when two or more processes are sharing a page, and one of them attempts to modify the page. To preserve the semantics of the UNIX fork() primitive, a copy of the shared page is made for the process, and it is then allowed to modify that page at will. mmmmoooodddd _M_o_d_i_f_i_e_d faults occur the first time a process modifies a page, which tells the operating system that the page is dirty. For unmodified pages, the kernel can go to the filesystem to get a copy of the page, which saves the overhead of keeping a copy on swap during paging. A copy of all modified pages must be maintained in memory or on swap. ddddmmmmdddd _D_e_m_a_n_d-_f_i_l_l faults occur the first time a process references a page with which there is no associated backing-store, for instance when first touching the BSS segment in a program. Since BSS is guaranteed to be zero, it is not kept in the object file, but is allocated to the process on demand by the kernel. ccccaaaacccchhhheeee During paging, the kernel keeps a pool of pages which have been selected as candidates for stealing, and have backing store containing a copy of the page. This allows the kernel to respond to memory allocation needs quickly, while allowing a process to get back a page quickly if it touches it again. This pool is called the _p_a_g_e _c_a_c_h_e. Each _c_a_c_h_e event indicates that a page fault occurred and the desired page was found in the page cache. PPPPaaaaggggeeee 11111111 GGGGRRRR____OOOOSSSSVVVVIIIIEEEEWWWW((((1111)))) GGGGRRRR____OOOOSSSSVVVVIIIIEEEEWWWW((((1111)))) ffffiiiilllleeee _F_i_l_e events occur when a page fault happens and a copy of the required page is fetched from the file system. sssswwwwaaaapppp This event indicates that a page fault occurred, and the desired page was fetched from the disk swap area. ddddoooouuuubbbblllleeee This event indicates that a second-level fault has occurred. On the 4D series, translation lookaside buffer (TLB) handling is performed entirely by software. This is done by looking up the missing page entry in a page table, and entering the virtual to physical mapping into the TLB. First-level faults are handled by extremely efficient low-level software. The page tables themselves are virtually mapped, so when the first level TLB handler attempts to load a page table entry, it may fault because the page table isn't mapped. This is a second- level fault, and must be repaired by high-level kernel routines. ppppggggrrrreeeeffff This event indicates that a page fault occurred, but the page was actually still attached to the user address space. Reference faults are used by the operating system to keep accurate usage information when paging is imminent. ppppsssswwwwaaaapppp The page swapping activity monitor bar (titled "Pages Swapped") measures access to the swap areas, for either swapin or swapout activity. During heavy paging, both swapin and swapout activity could be significant. On a system with only a single swap area on the same disk as the system and user data, the swapping rate will be effectively limited by the disk latency. Much higher swapping rates are possible with several swap areas configured across multiple disks and disk controllers. This may be necessary to achieve reasonable throughput in the face of many large jobs competing for main memory. The _p_s_w_a_p bar is different than the _s_w_p bar described elsewhere; while _p_s_w_a_p measures pages swapped in and out, the _s_w_p bar measures the usage of logical swap space. nnnneeeettttttttccccpppp This bar measures data throughput for the TCP network protocol, in kilobytes per second. TCP, standing for TTTTransmission CCCControl PPPProtocol, is a reliable connection oriented protocol used mainly for stream oriented operation, such as remote login or file copy. nnnneeeettttuuuuddddpppp This bar measures data throughput for the UDP network protocol, in datagrams. IIIINNNNddddggggrrrraaaammmm and OOOOUUUUTTTTddddggggrrrraaaammmm measure the datagram throughput, while DDDDrrrrooooppppppppeeeedddd measures the number of datagrams dropped. UDP, the UUUUser DDDDatagram PPPProtocol, is a datagram service used where low latency transactions are useful. For instance, the Sun Remote Procedure Call protocol uses UDP. The NFS filesystem is PPPPaaaaggggeeee 11112222 GGGGRRRR____OOOOSSSSVVVVIIIIEEEEWWWW((((1111)))) GGGGRRRR____OOOOSSSSVVVVIIIIEEEEWWWW((((1111)))) based on SunRPC, and therefore UDP activity is a good indicator of NFS activity. nnnneeeettttiiiipppp This bar measures packet throughput for the IP network protocol. IIIINNNNppppaaaacccckkkk and OOOOUUUUTTTTPPPPaaaacccckkkk measure the number of packets, while DDDDrrrrooooppppppppeeeedddd measures the number of packets dropped by the protocol. In numeric mode, additional fields are:FFFFoooorrrrwwwwaaaarrrrdddd, giving the number of packets forwarded on to another host and DDDDeeeelllliiiivvvveeeerrrreeeedddd, giving the number of packets handed over to an upper-layer protocol. IP, standing for IIIInternet PPPProtocol, is the basic packet management layer of the network. It sits between the network interface driver and higher level protocols, providing error control and routing facilities. nnnneeeettttiiiiffff This bar monitors packets transmitted or received through the various network interfaces which may be present on a machine. If displayed as a regular bar, the number of packets transferred in or out over the interface is shown as IIIINNNNppppaaaacccckkkk or OOOOUUUUTTTTppppaaaacccckkkk. If displayed as a numeric bar, then three additional fields may be displayed: IIIINNNNeeeerrrrrrrr and OOOOUUUUTTTTeeeerrrrrrrr measure the number of packets received in error or which had errors during transmission, while ccccoooollllllll measures the number of packet collisions which occurred, which only happens on CSMA/CD interfaces. Each machine supporting networking has a local loopback interface called _l_o_0. This interface is not usually displayed unless specifically called out, and it does not have the IIIINNNNeeeerrrrrrrr, OOOOUUUUTTTTeeeerrrrrrrr and ccccoooollllllll fields. ttttllllbbbb The ttttllllbbbb monitor bar measures translation lookaside buffer (TLB) activity on the system. mmmmppppssssyyyynnnncccc counts how many times a request is made to flush all TLB entries on all processors and vvvvmmmmwwwwrrrraaaapppp indicates how many times mmmmppppssssyyyynnnncccc is caused by a depletion of clean (with respect to the TLB) kernel virtual addresses. fffflllluuuusssshhhh counts how many times an entire TLB is flushed on any one processor and iiiiddddwwwwrrrraaaapppp shows how many times this happens because a processor's TLB ids have been depleted. iiiiddddggggeeeetttt monitors TLB id allocation and iiiiddddppppuuuurrrrggggeeee counts how many times a tlb id is forcefully removed from a process. Lastly, vvvvaaaappppuuuurrrrggggeeee counts individual tlb entries being purged. iiiinnnnttttrrrr The interrupt monitor bar measures the interrupt rate in the system, and is broken out into VME interrupts and others, which are typically local interrupts to the CPU chip, such as serial I/O ports. The operating system clock also interrupts the CPU at 100HZ, thus at least this interrupt rate will always show as a background value. A large interrupt value, coupled with extremely sluggish performance, may indicate hardware problems, such as continuously interrupting device. PPPPaaaaggggeeee 11113333 GGGGRRRR____OOOOSSSSVVVVIIIIEEEEWWWW((((1111)))) GGGGRRRR____OOOOSSSSVVVVIIIIEEEEWWWW((((1111)))) ddddiiiisssskkkk The disk monitor bar comes in two flavors, an EFS version and an "everything else" version. In the EFS version, the first two parameters specify the space taken by the used and free I-nodes on the volume. The third is the space used by files, and any remainder is free space. In the non-EFS version, only the space used by files is shown. The ttttrrrraaaacccckkkkssssuuuummmm and mmmmaaaaxxxx values are the number of bytes used on the file system. sssswwwwpppp This bar monitors the amount of logical swap space on the system. If swap space is added or deleted, the bar will update to the appropriate values automatically. The total amount of logical swap space is computed as the sum of the amount of physical memory available to processes plus the amount of physical swap space plus the amount of virtual swap space. Physical swap space is further divided into free and used. Logical swap is reserved (used) by processes' private mappings (see _s_w_a_p(1m) for more information on private mappings). The sssswwwwpppp bar combines these two kinds of information (logical swap makeup and reserved logical swap) by splitting each of the four parts that make up the sum logical swap into two pieces - reserved and available. The 8 components of this bar are: mmmmeeeemmmm The amount of physical memory available to processes that is not reserved. mmmmeeeemmmm----rrrr The amount of physical memory available to processes that is reserved. ffffsssswwwwpppp The amount of physical swap that is neither allocated nor reserved. ffffsssswwwwpppp----rrrr The amount of physical swap that is not allocated but is reserved. uuuusssswwwwpppp The amount of physical swap that is allocated but not reserved. uuuusssswwwwpppp----rrrr The amount of physical swap that is allocated and reserved. vvvvsssswwwwpppp The amount of virtual swap that is not reserved. vvvvsssswwwwpppp----rrrr The amount of virtual swap that is reserved. The ttttrrrraaaacccckkkkssssuuuummmm and mmmmaaaaxxxx values are the number of bytes of logical swap reserved. PPPPaaaaggggeeee 11114444 GGGGRRRR____OOOOSSSSVVVVIIIIEEEEWWWW((((1111)))) GGGGRRRR____OOOOSSSSVVVVIIIIEEEEWWWW((((1111)))) EXAMPLE The following description file gives a layout identical to that used when the -a option of _g_r__o_s_v_i_e_w _i_s _g_i_v_e_n: cpu rmem max tracksum wait sysact max gfx FFFFIIIILLLLEEEESSSS /usr/sbin/gr_osview $HOME/.grosview SSSSEEEEEEEE AAAALLLLSSSSOOOO gr_top(1), ps(1), top(1). BBBBUUUUGGGGSSSS When using a strip chart display, and some other window obscures part of the strip chart, the bar will gradually turn to black. This is because an in-framebuffer copy operation is used to make the strip appear to move, and when part of the window is obscured there is nothing to copy. It is not clear that this bug will ever be fixed, because of the performance advantages of this style of update. If the gr_osview window is redrawn, perhaps due to a repaint or resizing of the window, the next tick mark to be drawn on the strip may be drawn at an incorrect position. Following marks will have correct position and interval. If the _a_r_b_s_i_z_e option is used, a tiny window can be drawn which is unintelligible. It is assumed that if the _a_r_b_s_i_z_e option is given, then a truly arbitrary size is desired. A global colors option will only affect bars declared after the colors declaration. It seems that this is the proper behavior, since it allows groups of bars to be set to the same colors. If a small window is used, and a width greater than one is specified, the bar header and variable names may continue beyond the end of the bar. This does not effect the operation of the program, but may cause some visual confusion. If you use _c_s_h(1), _g_r__o_s_v_i_e_w does not work if your ._c_s_h_r_c file on the remote host unconditionally executes interactive or output-generating commands. Put these commands inside the following conditional block: if ($?prompt) then endif PPPPaaaaggggeeee 11115555 GGGGRRRR____OOOOSSSSVVVVIIIIEEEEWWWW((((1111)))) GGGGRRRR____OOOOSSSSVVVVIIIIEEEEWWWW((((1111)))) so they won't interfere with _g_r__o_s_v_i_e_w and other non-interactive, _r_c_m_d(3N)-based programs. PPPPaaaaggggeeee 11116666 
